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ABSTRACT 



A requesting terminal includes an interface that allows a user 
to select whether data downloaded from a network (such as 
the Internet) is transmitted to the requesting terminal via a 
high-speed link, such as a satellite link, or a lower speed 
link, such as a terrestrial link- Preferably, the terrestrial link 
(which may comprise a conventional dial-up Internet 
connection) is a two-way link, wherein the requesting ter- 
minal transmits data requests to the network via the terres- 
trial link. The data requests generated by the requesting 
terminal are modified to designate whether the requested 
data should be downloaded from the network via the ter- 
restrial link or the satellite link. The terrestrial link may also 
be automatically selected for certain applications. 

10 Claims, 12 Drawing Sheets 
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METHOD AND APPARATUS FOR 

SELECTIVELY RETRIEVING 
INFORMATION FROM A SOURCE 
COMPUTER USING A TERRESTRIAL OR 
SATELLITE INTERFACE 

RELATED APPLICATIONS 

This application is a continuation-in-part of U.S. appli- 
cation Ser. No. 08/257,670, filed Jun. 8, 1994, now 
abandoned, entitled "Method and Apparatus for Requesting 
and Retrieving Information From a Source Computer Using 
Terrestrial and Satellite Interfaces." 

BACKGROUND OF THE INVENTION 

This application relates to a computer network and, more 
specifically, to a method and apparatus for allowing both 
high-speed and regular-speed access to a computer network. 

The Internet is an example of a TCP/IP network. The 
Internet has over 10 million users. 

Conventionally, access to the Internet is achieved using a 
slow, inexpensive method, such as a terrestrial dial-up 
modern using a protocol such as SUP (Serial Line IP), PPP, 
or by using a fast, more expensive method, such as a 
switched 56 Kbps, frame relay, ISDN (Integrated Services 
Digital Network), or H. 

Users generally want to receive (download) large amounts 
of data from networks such as the Internet. Thus, it is 
desirable to have a one-way link that is used only for 
downloading information from the network. A typical user 
will receive much more data from the network than he sends. 
Thus, it is desirable that the one-way link be able to carry 
large amounts of data very quickly. What is needed is a high 
bandwidth one-way link that is used only for downloading 
information, while using a slower one-way link to send data 
into the network. 

Currently, not all users have access to high speed links to 
networks. Because it will take a long time to connect all 
users to networks such as the Internet via physical high- 
speed lines, such as fiber optics lines, it is desirable to 
implement some type of high-speed line that uses the 
existing infrastructure. 

Certain types of fast network links have long propagation 
delays. For example, a link may be transmitting information 
at 10 Mbps, but it may take hundreds of milliseconds for a 
given piece of information to travel between a source and a 
destination on the network. In addition, for even fast low- 
density links, a slow speed return-link may increase the 
round trip propagation time, and thus limit throughput. The 
TCP/IP protocol, as commonly implemented, is not 
designed to operate over fast links with long propagation 
delays. Thus, it is desirable to take the propagation delay 
into account when sending information over such a link. 

SUMMARY OF THE INVENTION 

A first embodiment of the present invention overcomes 
the problems and disadvantages of the prior art by allowing 
a user to download data using a fast one-way satellite link, 
while using a conventional low-speed Internet connection 
for data being sent into the network. 

A second embodiment of the present invention allows a 
user to specify for certain applications that data be down- 
loaded from the Internet via a terrestrial link, rather than the 
satellite link. 

According to one aspect of the present invention, a system 
for retrieving data from a source computer coupled to a 



52,721 

2 

network comprises a low- speed path linking a requesting 
terminal with the network, a high-speed path linking the 
requesting terminal with the network, and means for select- 
ing either the low-speed path or the high-speed path for 

5 transmission of data from the source computer to the 
requesting terminal. In a preferred embodiment, the low- 
speed path is a terrestrial link, wherein the terrestrial link is 
a two-way link between the requesting terminal and the 
network comprising a serial port in the requesting terminal 

10 in communication with a SLIP provider connected to the 
network. The high-speed path is a satellite link, wherein the 
satellite link is a one-way link comprising a gateway con- 
nected to the network wherein data retrieved from the source 
computer is provided to the gateway via the network and 

15 transmitted to the requesting terminal via the satellite link. 
The requesting terminal generates a data request packet that 
is sent to the source computer via the terrestrial link. The 
selection means comprises a driver in the requesting termi- 
nal that modifies the request packet to specify either the 

20 low-speed path or the high-speed path. The selection means 
may also include a user interface in the requesting terminal 
that allows a user to specify that certain applications use the 
low-speed path. 
According to another aspect of the present invention, a 

25 system for retrieving data from a source computer coupled 
to a network comprises a requesting terminal for requesting 
data to be retrieved from the source computer. The request- 
ing terminal includes a terrestrial interface coupled to the 
network, and a satellite interface capable of receiving data 

30 transmitted via satellite link, wherein the satellite link 
includes a gateway coupled to the network. The requesting 
terminal further includes means for designating that the 
requested data be transmitted from the source computer to 
the requesting terminal through either the terrestrial inter- 

35 face or the satellite interface. 

According to yet another aspect of the present invention, 
a method of retrieving data from a source computer coupled 
to a network comprises the steps of generating, at a request- 
ing terminal, a request packet for transmission of data from 

40 the source computer, designating, at the requesting terminal, 
a transmission path selected from either a low-speed path 
(such as a terrestrial link) or a high-speed path (such as a 
satellite link) for transmission of the requested data from the 
source computer to the requesting terminal, providing the 

45 designated data request to the source computer, wherein the 
source computer generates a data reply, and receiving the 
data reply from the source computer via the designated 
transmission path. 

5Q Objects and advantages of the invention will be set forth 
in part in the description which follows and in part will be 
obvious from the description or may be learned by practice 
of the invention. The objects and advantages of the invention 
will be realized and attained by means of the elements and 

55 combinations particularly pointed out in the appended 
claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The accompanying drawings, which are incorporated in 
60 and constitute a part of this specification, illustrate several 
embodiments of the invention and, together with the 
description, serve to explain the principles of the invention. 

FIG. 1 is a hardware block diagram of a preferred 
embodiment of the invention; 
65 FIG. 2 is a diagram of a portion of a hybrid terminal of 
FIG. 1; 

FIG. 3 is a diagram showing an IP packet format; 
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FIG. 4 is a diagram showing a plurality of packet formats, the satellite earth station hardware. In the past, these costs 

including an Ethernet packet format; have placed satellite communications outside the reach of 

FIG. 5 is a diagram showing a tunneling packet format; me consumer. 

FIG. 6 is a diagram of steps performed by the hybrid ™ B P reset * ideation allows a personal computer to 

terminal of FIG V 5 receive downloaded information from the network via a 

- .... satellite at a very practical cost. In the present invention, the 

FIG. 7 is a diagram showing an example of partial data in CQSt of satellite communicaLions is reduced becausc a one . 

a tunneling packet; way satellite link is R ece ive-only earth station equip- 

FIG. 8 is a flowchart of steps performed by the hybrid men t is cheaper to manufacture because it requires less 

terminal of FIG. 1; 10 electronics than send/receive antennae. 

FIG. 9 is a diagram of steps performed by a hybrid As is we 11 -know in the art, communication over the 

gateway of FIG. 1; Internet and similar TCP/IP networks is achieved through a 

FIG. 10 is a diagram showing a format of packets sent to group (suite) of protocols called Transmission Control 

a satellite gateway of FIG. 1; Protocol/Internet Protocol (TCP/IP). The TCP/IP protocol is 

FIG. 11 is a diagram showing a TCP packet format; 15 described in the book "Internetworking With TCP/IP, VOL 

-,^ , 11J . < ^ I by Douglas Comer, published by Prentice-Hall, Inc., of 

FIG 12 is a ladder diagram showing packets sent from an En ^ ewood CWs NJ 1991> which k mcorporat ed by 

application server to the hybrid gateway and from the hybrid reference 

gateway to the hybrid terminal over a satellite link; b ny^d TCP/IP Access 

FIGS. 13(a) through 13(e) are flowcharts of steps per- 20 FIG. 1 is a hardware block diagram of a preferred 

formed by the hybrid gateway of FIG. 1; embodiment of the invention. FIG. 1 includes five sub- 

FIG. 14 is a diagram of an example of a graphical user systems: a hybrid terminal 110, a SLIP provider (Internet 
interface which allows a user to select applications that will connection) 130, an application server 140, a hybrid gate- 
use a terrestrial link, rather than the satellite link, for way 150, and a satellite gateway 160. Hybrid terminal 110 
downloading data; 25 is connected to a modem 190, e.g., a 9600 baud modem, 

FIG. 15 is a simplified hardware block diagram of the which connects to SLIP provider 130 through a telephone 

present invention illustrating satellite and terrestrial request line 192. A satellite transmitter 170, a satellite 175, and a 

and reply paths; satellite receiver 180 provide a fast, one-way link for trans- 

FIG. 16 is a block diagram illustrating the transfer of data ^™ data from satellite S atewa y 160 10 h y brid terminal 

packets between components of the hybrid terminal; and 30 U0 " Satelllte transmitter 170, satellite 175 and satellite 

r-r^o +sr^ j- <• . i receiver 180, however, do not themselves necessarily com- 

F1GS. 16A-16E are diagrams of the data packets repre- 4 nu t - r u r CI Tn 

a ' err 1 « prise a part of the present invention. Each of SLIP provider 

sented in MU. lb. 13Q app]ication 140 ^ hybrid gateW ay 150 are 

DETAILED DESCRIPTION OF THE connected to the Internet 128. As is well-known in the art, 

PREFERRED EMBODIMENTS 35 tne mternet 128 is a "network of networks" and can be 

visually depicted only in general terms, as seen in FIG. 1. 

Reference will now be made in detail to the preferred E acn Q f hybrid terminal 110, SLIP provider 130, appli- 

embodiments of the invention, examples of which are illus- cation server 140, hybrid gateway 150 and satellite gateway 

trated in the accompanying drawings. Wherever possible, 160 preferably includes a processor (not shown) that 

the same reference numbers will be used throughout the 40 executes instructions stored in a memory (not also shown). 

drawings to refer to the same or like parts. Other parts of the invention may also include processors that 

t o attt r ttt t tktta are not discussed herein, such as I/O processors, etc. 

I. SATELLITE LINK n - . . , , . , i . ' 11A , , \ ^ ' 

Preferably, hybrid terminal HO, hybrid gateway 150, and 

According to a first embodiment of the present invention, satellite gateway 160 are implemented as personal comput- 

all information downloaded from the Internet is received via 45 ers including an 80386/80486 or Pentium based personal 

a high speed satellite link, as described in detail below. computer operating at at least 33 MHz, but these elements 

a. General Overview can be implemented using any data processing system 

A preferred embodiment of the present invention uses capable of performing the functions described herein, 

satellite technology to implement a high-speed one-way link Alternatively, the functionality of both hybrid gateway 150 

between a user's computer and a TCP/IP network, such as 50 and satellite gateway 160 could be performed in a single 

the Internet or a private TCP/IP network. This high-speed gateway unit (not shown) without departing from the spirit 

link is used to download data from the network. The user's or scope of the present invention. In the described 

computer also has a conventional TCP/IP link for sending embodiment, SLIP provider 130 is a conventional SLIP 

data to the network. The invention can use various forms of provider and:application server 140 is any application server' . 

high-speed, one-way links, such as satellites and cable 55 <^hat can connect to the Internet 128 via TCP/IP., 

television lines. The invention can use various forms of "As shown in FIG. I, hybrid terminal HO preferably also 

low-speed networks, such as TCP/IP networks, dialup includes application software 112, driver software 114, a 

telephones, ISDN D-channel, CPDP, and low-speed satellite serial port 122 for connecting hybrid terminal HO to modem 

paths. 1 90, and satellite interface hardware 120 for connecting 

The described embodiment of the present invention uses 60 hybrid terminal HO to satellite receiver 180. 

satellites to provide a high-speed one-way link. Satellites FIG. 2 shows a relationship between software in appli- 

can cover large geographical areas and are insensitive to the cation 112, software in driver 114, serial port 122, and 

distance between a transmitter and a receiver. In addition, satellite interface 120. Application software 112 preferably 

satellites are very efficient at point-to-point and broadcast includes TCP/IP software, such as SuperTCP, manufactured 

applications, and are resilient and resistant to man-made 65 by Frontier, Inc., Chameleon, manufactured by Netmanager, 

disasters. Two-way satellites are expensive to use, however, and IRNSS, manufactured by SPRY, Inc. The described 

because of the costs involved in purchasing and installing embodiment preferably operates with the SuperTCP TCP/IP 
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package and, thus, uses a standard interface 212 between the 
TCP/IP software 210 and driver 114. Examples of standard 
interface 212 between TCP/IP software 210 and driver 114 
include the Crynson-Clark Packet Driver Specification and 
the 3Com/Microsoft Network Driver Interface Specification 5 
(NDIS). Other embodiments within the scope of the inven- 
tion may use other standard or non-standard interfaces 
between TCP/IP software 210 and driver 114. 

Ik^hpwh in.F^^ 
also includes well-know Internet utilities, such as FTP 230$ 10 
and well-known user interfaces, such as Mosaic and Gopbej| 
(shown). Application software 112 can algpiBelud|^gtheJ^ 
utiUties^e.g^^ 

The following paragraphs describe how a request from 
hybrid terminal 110 is carried through the Internet 128 to 15 
application server 140 and how a response of application 
server 140 is carried back to the user at hybrid terminal 110 
via the satellite link. (As used herein, the term "satellite link" 
refers to any portion of the path between application server 
140, the Internet 128, satellite gateway 160, satellite trans- 20 
nutter 170, satellite 175, satellite receiver 180 and hybrid 
terminal 110). The operation of each subsystem will be 
described below in detail in separate sections. 

In the present invention, hybrid terminal 110 is given two 
IP addresses. One IP packet address corresponds to SLIP 25 
provider 130 and is assigned by a SLIP service provider. The 
other IP address corresponds to satellite interface 120 and is 
assigned by a hybrid service provider. IP addresses are 
assigned by the SLIP and satellite network managers and 
loaded into hybrid terminal 110 as part of an installation 30 
configuration of the hybrid terminal's hardware and soft- 
ware. These two IP interface addresses correspond to com- 
pletely different physical networks. SLIP provider 130 does 
not "know" anything about the satellite interface IP address 
or even whether the user is using the satellite service. If a 35 
host somewhere in the Internet is trying to deliver a packet 
to the satellite IP address by using the Internet routing 
scheme of routers, gateways, and ARPs (Address Resolution 
Protocol), the only way that the packet can reach the satellite 
interface IP is to traverse the satellite by being routed 40 
through satellite gateway 160. 

The following example assumes that a user at hybrid 
terminal 110 desires to send a request to a remote machine, 
such as application server 140 that is running FTP (File 
Transfer Protocol) server software. The FTP software run- 45 
ning on application server 140 receives file transfer requests 
and responds to them in an appropriate fashion. 

FIG. 3 shows the contents of a source field (SA) and of a 
destination field (DA) of packets sent between the elements 
of FIG. 1. A request for a file and a response of a file sent 50 
from application server 140 to hybrid terminal 110 may take 
the following path. 

1) Within hybrid terminal 110, FTP client software 230 
generates a request and passes it to TCP/IP software 
210. TCP/IP software 210 places the request in a TCP 55 
packet (see FIG. 11). Next, the TCP packet is placed in 
an IP packet, having a format shown in FIG. 3. TCP/IP 
software 210 places the IP packet in an Ethernet packet, 
as shown in FIG. 4, and passes the Ethernet packet to 
driver 114. This packet has a source IP address corre- 60 
sponding to satellite interface 120 and a destination IP 
address of application server 140. Ethernet is a packet 
switching protocol standardized by Xerox Corporation, 
Intel Corporation, and Digital Equipment Corporation, 
which is described in "The Ethernet" A Local Area 65 
Network Data Link Layer and Physical Layer 
Specification/' September 1980, which is available 
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from any of these three companies, and which is 
incorporated by reference. 

2) In driver 114, the Ethernet header and checksum are 
stripped off the packet and the IP packet is 
encapsulated, or "tunneled," inside of another IP 
packet, and sent over serial port 122 to SLIP provider 
130. FIG. 5 shows a format of a tunneled packet. FIG, 
7 shows an example of a tunnelled packet. The encap- 
sulation adds a new IP header 530 in front of the 
original packet 540 with a source address correspond- 
ing to SLIP provider 130 and a destination address 
corresponding to hybrid gateway 150. 

3) SLIP provider 130 receives the IP packet, analyzes the 
tunneling header and, thinking it is destined for hybrid 
gateway 150, uses standard Internet routing to send the 
packet to hybrid gateway 150. 

3) When hybrid gateway 150 receives the packet, it strips 
off the tunneling header, revealing the true header with 
application server 140 as the destination. The packet is 
then sent back out into the Internet 128. 

5) Internet routing takes the packet to application server 
140, which replies with the requested file and addresses 
the reply to the request's source IP address, i.e., the IP 
address of the hybrid terminal's satellite interface 120. 

6) In order to find the hybrid terminal's satellite interface 
120, the Internet routing protocol will send the packet 
to the subnet containing a router/gateway connected to 
hybrid gateway 150. When a router on the same physi- 
cal network as satellite gateway 160 and hybrid gate- 
way 150 sends out an ARP for the IP address of satellite 
interface 120 (to find a physical address of satellite 
interface 120), hybrid gateway 150 responds and says 
"send it to me." Thus, application server 140 and the 
rest of the Internet 128 think that packets sent to hybrid 
gateway 150 will reach the hybrid terminal's satellite 
interface. 

7) Once hybrid gateway 150 receives a reply packet from 
application server 140, it sends it to satellite gateway 
160. In the described embodiment, hybrid gateway 150 
encapsulates the packet in a special packet format that 
is used over the satellite link and uses the satellite 
interface IP address to uniquely identify the satellite 
packet's destination. Then hybrid gateway 150 sends 
the packet over the Ethernet to satellite gateway 160. 

8) Satellite gateway 160 broadcasts over the satellite link 
any packets it receives from hybrid gateway 150. 

9) Driver 114 in hybrid terminal 110 that services satellite 
interface 120 scans all packets broadcast over satellite 
transmitter 170 looking for its satellite interface IP 
address in the header. Once it identifies one, it captures 
it, strips off the satellite header revealing the reply IP 
packet, and sends it to driver 114. 

Thus, IP packets sent into Internet 128 are carried by the 
SLIP connection, while IP packets from the Internet 128 are 
carried by the satellite link. The following paragraphs 
describe the operation of each subsystem in more detail. 

1. The Hybrid Terminal 

Hybrid terminal 110 is the terminal with which the user 
interacts. Thus, hybrid terminal 110 preferably includes a 
user interface device (not shown) such as a mouse, 
keyboard, etc. As shown in FIG. 1, hybrid terminal 110 
includes one or more application programs 112 (including 
TCP/IP software 210), and driver software 114, which 
communicates with SLIP provider 130 through a serial port 
122 and modem 190, using a serial driver portion 118, and 
which communicates with satellite receiver 180 through a 
satellite interface 120, using a driver portion 116. 
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To TCP/IP software 210, driver 114 appears to be an 
Ethernet card, although driver 114 is actually connected to 
satellite receiver 180 (via satellite interface 120) and to SLIP 
provider 130 (via serial line 122 and modem 190, 
respectively). Thus, TCP/IP software 210 believes that it is 
communicating with a single physical network, when it is, in 
reality, communicating with two physical networks (the 
SLIP dial up network and a satellite network). 

FIG. 6 is a diagram of steps performed by driver 114 of 
hybrid terminal 110 of FIG. 1. As shown in FIG. 6, driver 
114 receives packets of data from TCP/IP software 210 and 
passes them to SLIP provider 130 via serial port 122 and 
modem 190. A packet sent by application server 140 is 
received through satellite receiver 180, passed through the 



10 



the Ethernet header on packets from TCP/IP before the 
packets are sent to SLIP provider 13. 
C. Other Functions 
As shown in step 630 of FIG. 6, packets received by 
driver 114 from satellite receiver 180 (via satellite driver 
114) are passed to TCP/IP software 210. The following 
paragraphs discuss implementation details for the described 
embodiment. 

In a preferred embodiment, TCP/IP software 210 (e.g., 
Frontier's SuperTCP) sends an ACK ( acknowledge) for 
every packet it receives, even though this action is not 
required by the TCP/IP protocol. In this situation, many 
packets compete for the slow link to SLIP provider 130. In 
TCP/IP, the ACK scheme is cumulative. This means that 



satellite interface 120, passed to the satellite driver 220, and 15 when a transmitter receives an ACK stating that the receiver 



has received a packet with sequence number N, then the 
receiver has received all packets with sequenced numbers up 
to N as well, and there is no reason why every packet needs 
to be ACK'ed. 

FIG. 8 is a flowchart of steps performed in a preferred 
embodiment by driver 114 of hybrid terminal 110. FIG, 11 
is a diagram showing a preferred TCP packet format. FIG, 
11 includes a sequence number field 1102, an acknowledg- 
ment (ACK) number field 1104, and a checksum field 1106. 



passed to driver 114, which passes the received packet to 
TCP/IP software 210. 

The following paragraphs discuss two basic functions 
performed by driver 114 (tunneling and ARP handling) and 
discuss various implementation details for the preferred 20 
embodiment. 

A. "Tunnelling"' 

As discussed above, hybrid terminal 110 has two IP 
addresses associated with it: one for SLIP provider 130 and 
one for the satellite interface 120. Packets containing 25 In step 810 of FIG. 8, driver 114 receives an ACK packet 
requests are sent from hybrid terminal 110 to application with sequence number N from TCP/IP software 210. The 
server 140 via the Internet 128, while packets containing a packet is queued along with other packets waiting to be sent 
reply are sent back via the satellite link. Tunneling is the to SLIP provider 130. In step 820 driver 114 checks to 
method by which application server 140 is 'Tooled" into determine whether there is a "run" of sequential packets 
sending a reply to a different IP address (satellite interface 30 waiting to be sent. If so, in step 830, driver 114 deletes ACK 
120) than that of the sender (serial port 122). packets for the same TCP connection that have sequence 

A packet received by driver 114 from the TCP/IP software numbers in the run from the queue and sends an ACK only 
210 has a source address of satellite gateway 160 and a for the highest sequence number in the run. This action 
destination address of application server 140. As shown in alleviates the bottleneck caused by the relatively slow 
step 610 of FIG. 6, driver 114 removes the Ethernet header 35 modem speeds. 

and checksum and encapsulates the IP header into an IP Serial port 122 provides a physical connection to modem 
tunnelling header having a source address of SLIP provider 190 and, through it, to the terrestrial network via a SLIP 
130 and a destination address of hybrid gateway 150 (see protocol as described below in connection with SLIP pro- 
FIG. 7). As described above, at hybrid gateway 150, the vider 130. Serial data is sent and received through an 
tunnelling header is removed and the packet is sent back into 40 RS-232 port connector by a UART (Universal Asynchro- 



the Internet 128 to be sent to application server 140. 

When forming a tunneling header, driver 114 copies all 
the values from the old header into the new one with the 
following exceptions. The source and destination addresses 
of the tunneling header change, as described above. In 45 
addition, a total packet length field 510 is changed to contain 
the contents of length field 310 plus the length of the 
tunneling header. Lastly, the driver 114 recalculates check- 
sum 520 of the tunneling header because some of the fields 
have changed. 

B. ARP Handling 

ARP (Address Resolution Protocol) is used by TCP/IP to 
dynamically bind a physical address, such as an Ethernet 
address, to an IP address. When TCP/IP finds an IP address 



nous Receiver Transmitter), such as a U8250, which has a 
one byte buffer and is manufactured by National 
Semiconductor, or a U16550, which has a 16 byte buffer and 
is also manufactured by National Semiconductor. 

The invention preferably operates under the DOS oper- 
ating system and Windows, but also can operate under other 
operating systems. 

Satellite driver software 220 receives packets from satel- 
lite 180, and passes them to driver 114 using a DOS call. 
50 Thus, the two physical links are combined within driver 114 
and the existence of two physical links is transparent to 
TCP/IP software 210. Satellite driver 220 scans all packets 
transmitted over the satellite channel for a packet with a 
header corresponding to the IP address of the satellite 



for which it does not know a physical address, TCP/IP 55 interface 122, performs some error detection and correction 



broadcasts an ARP packet to all nodes, expecting a response 
that tells TCP/IP what physical address corresponds to the IP 
address. 

During initialization, driver 114 declares to TCP/IP soft- 
ware 210 that driver 114 is an Ethernet card to ensure that 
the packets that TCP/IP package sends are Ethernet packets 
and that the TCP/IP package will be prepared to receive 
packets at a high -rate of speed. As shown in step 620 of FIG. 
6, when driver 114 detects that TCP/IP has sent an ARP 



on the packet, buffers the received packet, and passes the 
packet to driver 114 using a DOS call, e.g., IOCTL-output- 
cmd( ). Driver 114 copies data from satellite driver 220 as 
quickly as possible and passes it to TCP/IP software 210. 

As discussed above, TCP/IP software 210 is fooled into 
thinking that it is connected to an Ethernet network that can 
send and receive at 10 Mbps. This concept is helpful on the 
receive side because data from the satellite is being received 
at a high rate. On the transmit side, however, modem 190 is 



packet, driver 114 creates a physical address and sends a 65 not capable of sending at such a high rate. In addition, 
reply packet to TCP/IP software 210. The contents of the TCP/IP software 210 sends Ethernet packets to driver 114, 
physical address are irrelevant, because driver 114 strips off i.e., an IP packet is encapsulated into an Ethernet packet. 
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Because SLIP provider 130 expects IP packets, driver 114 
must strip the Ethernet header before the packet is sent to 
SLIP provider 130. ^ 

As described above in connection with FIG. 8,.driver_114\ 
also includes a transmit and receive queue. As data is 5 
received from TCP/IP software 210 and received from th'e^ 
satellite driver 220, it is buffered within the queue. When the 
queue is full, e.g., when TCP/IP is sending packets faster 
than modem 190 can send them, driver J14dropsthe jackets 
and returns an error so that r TCP/IP software 210 will 
decrease^itsTafe of transmission. ^ 

In a first preferred embodiment, a SLIP connection is 
initiated with an automatic logon procedure. In another 
preferred embodiment, driver 114 executes instructions to 
allow a user to perform a SLIP logon manually. 

Because TCP/IP software 210 preferably is configured to 15 
talk to the Ethernet and it is desirable to receive the largest 
packet size possible, driver 114 configures TCP/IP so that 
the MTU (Maximum Transmission Unit) of the network is 
as large as possible, e.g., 1500 bytes. Some SLIP providers 
130 have a smaller MTU, e.g., 512 bytes. To handle the 20 
disparity in size, driver 114 segments large packets received 
from TCP/IP software 210 into segments the size of the SLIP 
MTU. Once a packet is segmented, it is reassembled in 
hybrid gateway 150. Only the tunnelling header is copied as 
the header of the segments. ^ 

2. The SLIP Provider 

SLIP provider 130 performs the function of connecting 
hybrid terminal 110 to the Internet 128. As described above, 
other protocols, such as PPP (point to point protocol), could 



A. Untunnelling 

FIG. 9 is a diagram of steps performed by hybrid gateway 
150 of FIG. 1. In step 910, hybrid gateway 150 receives a 
tunnelled packet having a format shown in FIG. 5. Hybrid 
gateway 150 "untunnels" the packet by stripping off the 
tunnelling header and passes the packet back to the Internet 
128. 

As described above, packets are sometimes broken into 
segments when they are sent in order to accommodate a 
small MTU of SLIP provider 130, Packets may also be 
segmented as they pass through other elements of the 
Internet 128 having small MTUs. For fragmented packets, 
only the tunnelled header is copied into the header of each 
segment. Hybrid gateway 150 stores fragmented packets in 
a memory (not shown) and reassembles them in order before 
untunnelling the original packet and passing it to the Internet 
128. Preferably, a "time to live" value is assigned to each 
packet when it is sent by driver 114 and if all segments do 
not arrive before a time to live timer expires, the packet is 
discarded. 

B. ARP Responding 

Preferably, satellite gateway 160 is on a same physical 
network as hybrid gateway 150. As shown in step 920 of 
FIG. 9, when a router on the same physical network as 
satellite gateway 160 and hybrid gateway 150 sends out an 
ARP for the IP address of satellite gateway 160 (to find a 
physical address of satellite gateway 160), hybrid gateway 
150 responds and says "send it to me." Hybrid gateway 150 
needs to intercept packets intended for satellite gateway 160 



also be used to perform the connecting function. SLIP server because it needs to encapsulate packets for satellite gateway 



130 receives SLIP encoded IP packets from modem 190, 
uncodes them, and forwards them to hybrid gateway 150 via 
the Internet 128. 

In its most basic form, SLIP provider 130 delimits IP 
packets by inserting a control character such as hex OxCO- 
SLIP between them. To insure that a data byte is not 
mistaken for the control character, all outgoing data is 
scanned for instances of the control character, which is 
replaced by a two character string. The SLIP protocol is 
described in detail in J. Romkey, "A Nonstandard for Trans- 



160 as follows. 

C. Satellite Packetizing 
The following paragraphs describe how packets travel 
from application server 140 through hybrid gateway 150 and 
35 to satellite gateway 160. The following explanation is given 
by way of example and is not intended to limit the scope of 
the present invention. As shown in step 930 of FIG. 9, hybrid 
gateway 150 encapsulates replies from application server 
140 into a satellite packet format. FIG. 10 is a diagram 
mission of IP Datagrams over Serial Lines: SLIP," RFC 40 showing a format of a satellite packet sent to satellite 
1055, June 1988, pp. 1-6, which is incorporated by refer- gateway 160 of FIG. 1. A satellite packet includes the data 
ence. 1010 of an original IP packet and two headers 1020, 1030 

3. The Application Server added by hybrid gateway 150. 

^g^tion^ryerJJ^s^^m^ter system running anyj? Satellite gateway 160 expects IP packets to be encapsu- 
combination of known application programsa vailablefon the 45 lated first in a special satellite packet and then within an 
Internet 128 using the TCP/IP protocol suite. For example, LLC-1 IEEE 802.2 link level control, type 1 packet. Satellite 
application server 140 may transfer files to requesting users header 1020 identifies the downlink and contains a sequence 
via FTP. In this regard, application server 140 may be number and the packet length. An LLC-1 header 1030 
thought of as a host computer. Although hybrid terminal 110 preferably is used to send the packet to satellite gateway 
actually has two IP addresses (a serial port address and an 50 160, in an Ethernet LAN. Hybrid gateway 150 prepares 



address for the satellite interface), the software executing on 
application server 140 thinks that it is receiving requests 
over the satellite network and sending responses over the 
satellite^network^Hybrid^erminal 110 is completely trans- 
parent to applicauon serveL140. 
4. The Hybrid Gateway 

Although only one hybrid terminal 110 is shown in FIG. 
1, the invention can include a plurality of hybrid terminals 
110. Preferably, all packets sent from all hybrid terminals 
110 pass through hybrid gateway 150 to get untunnelled. 60 
Thus, hybrid gateway 150 is a potential system bottleneck. 
Because of this potential bottleneck, the functions of hybrid 
gateway 150 are as simple as possible and are performed as 



packets for satellite gateway 160 by appending headers 1020 
and 1030 to the front of an IP packet 1010. 

The receiver in hybrid terminal 110 does not receive the 
LLC-1 header 1030. Hybrid terminal 110 identifies packets 
55 intended for it by checking a least significant byte in the 
satellite IP address. Thus, a six byte satellite destination 
address is determined by reversing an order of bytes of the 
satellite IP address for hybrid terminal 110 and then padding 
the rest of the address with zeroes. 
5. The Satellite Gateway 

Satellite gateway 160 can include any combination of 
hardware and software that connects satellite transmitter 170 
to hybrid gateway 150. Satellite transmitter 170 and satellite 
receiver 180 can be any combination of hardware and 



quickly as possible. Hybrid gateway 150 also has good 

Internet connectivity to minimize the accumulated delay 65 software that allows data to be transmitted by satellite 

caused by packets waiting to be processed by hybrid gate- transmitter 170 and received by satellite receiver 180, and to 

way 150. be input to hybrid terminal 110. For example, satellite 



01/01/2004, EAST Version: 1.4.1 



5,852,721 

11 12 

gateway 160 preferably is a personal computer with a sends an ACK#1 back to hybrid gateway 150 (e.g., using the 
high-speed Ethernet connection to hybrid terminal 110. tunneling mechanism described above). In a system that 
When satellite gateway 160 receives a packet from hybrid does not use tunneling, hybrid gateway 150 needs to inter- 
gateway 150, it sends it over the satellite link. cept the ACK packet from hybrid terminal 110. 

Satellite communication may be effected by, for example, 5 FIGS. 13(a) through 13(e) are flowcharts of steps per- 

the Personal Earth Station designed and manufactured by formed by hybrid gateway 150 of FIG. 1 during protocol 

Hughes Network Systems, Inc. In a preferred embodiment, spoofing. In step 1302 of FIG. 13(a), hybrid gateway 150 

a one-way version of the Personal Earth Station is used. receives a packet from application server 140 indicating that 

Another embodiment uses a satellite communication system a new connection is being formed between application 

manufactured by Comstream. Yet another embodiment uses 10 server 140 and hybrid terminal 110. In step 1304, hybrid 

a system that allows hybrid termiriaTllO to be connected gateway 150 sets up a queue or similar data structure in 

directiy to satellite receiver 180 via Hughes Network Sys-- memory to save un-ACK 3 ed packets for the new connection, 

terns' DirecPC product. The DirecPC satellite interface card FIG. 13(6) shows corresponding steps performed by hybrid 

is described in "DirecPC, Phase A Data Sheet/' dated Jun. l\ gateway 150 when the connection is closed. Hybrid gateway 

1993, which is attached as Appendix A, which is incorppp 15 150 receives a packet indicating the closure in step 1306 and 

rated in and constitutes a part of this specification, and which deletes the queue and saved values for the connection in step 

is . mcoip 6 rated by references " 1308. 

At the downlink, satellite receiver 180 includes a 0.6 In step 1310 of FIG. 13(c), hybrid gateway 150 fails to 

meter receive-only antenna receiving HDLC encapsulated receive an ACK for a packet number X from hybrid terminal 

LAN packets. Satellite interface 120 includes rate 2/3 20 110 before an end of a predetermined timeout period. Hybrid 

Viterbi/Reed-Soloman concatenated forward error correc- gateway 150 maintains a timer for each un-ACK J ed packet, 

tion. At the end of the predetermined period, hybrid gateway 150 

Although only one hybrid terminal 110 and one applica- retransmits a packet corresponding to the expired timer. In 

tion server 140 are shown in FIG. 1, the invention can step 1312, hybrid gateway 150 resends packet number X, 

include a plurality of hybrid terminals 110 and/or a plurality 25 which it previously saved in the memory queue for this 

of application servers 140. Preferably, all packets sent from connection (see FIG. 13(d) below). 

all application servers 140 to a hybrid interface 110 pass In step 1314 of FIG. 13(d), hybrid gateway 150 receives 

through a satellite gateway 160. Thus, satellite gateway 160 a packet from application server 140. In step 1316, hybrid 

is a potential system bottleneck. Because of this potential gateway 150 sends the received packet to satellite gateway 

bottleneck, the functions of satellite gateway 160 are as 30 160, where it is transmitted over the satellite link, and saves 

simple as possible and are performed as quickly as possible. the packet in case it needs to be retransmitted (see FIG. 

c. Protocol Spoofing 13(c)). Hybrid gateway 150 then creates an ACK packet to 

TCP/IP protocol specifies that only a predetermined num- send to application server 140 in step 1318. The created 

ber of packets can be outstanding during transmission, i.e., ACK packet incorporates a format shown in FIG. 11. Hybrid 

that only a limited number of packets can be sent before an 35 gateway 150 creates an ACK number for field 1104. The 

ACK (acknowledgment) is received. The high bandwidth ACK number is determined as follows: 

and long delays incurred in sending packets to an orbiting Hybrid gateway 150 saves the following information for 

satellite and back means that at any given time, a large each connection: 

number of packets may be "in the pipe" between transmitter i) Send sequence number— a highest insequence number 

and receiver. 40 G f packets sent by application server 140 over the 

When using conventional TCP/IP protocol, application connection 

server 140 sends a predetermined number of packets in 2) ACR s ence number _ the ACK nce number 

accordance with a predetermmed window size, and then from [he mos , receat ke , sen , b h bfid teminal uo 

waits to receive ACKs over the modem link before sending oyer ^ connec ti on 

additional packets. The purpose of windowing is to limit a 45 „ v mr . , . . , . 

numberof packets that must be re-sent if no ACK is received 3 > ACK window size-the window size from the most 

and to provide flow control, e.g., to prevent sending packets recent P acket from h V brid terminal 110 over this con " 

faster than they can be received. The packets that have not nection. 

been ACK'ed are stored in a memory so that they can be 4) ACK number— the ACK sequence number that is 

re-sent if no ACK is received. so relayed to application server 140. The ACK number is 

In a preferred embodiment of the present invention, set to: 

hybrid gateway 150 "spoofs" application server 140 to minimum (send sequence number, ACK sequence 

improve the throughput over the satellite link. Specifically, number+spoofed window size-ACK window size) 

hybrid gateway 150 sends an ACK to application server 140, 5) Spoofed window size — predetermined maximum num- 

even though a corresponding packet may not have been 55 ber window size to be allowed on this connection, 

received by hybrid terminal 110 via the satellite at the time. When hybrid gateway 150 inserts the ACK number in the 

FIG. 12 is a ladder diagram showing packets sent from packet, it also calculates the packet's checksum 1106. 

application server 140 to hybrid gateway 150 and from In step 1320 of FIG. 13(e), hybrid gateway 150 receives 

hybrid gateway to hybrid terminal 110 through the satellite an ACK packet over the modem link from hybrid terminal 

link. FIG. 12 is not drawn to scale. In FIG. 12, application 60 110. In step 1322, hybrid gateway 150 removes from the 

server 140 sends a message #1 to hybrid gateway 150. The queue the packet for which the ACK was received. Because 

propagation time for this transmission is relatively short. an ACK was received, the packet does not need to be re-sent. 

Hybrid gateway 150 immediately creates an ACK packet In the TCP/IP protocol, a packet containing an ACK may or 

and sends it to application server 140. Hybrid gateway 150 may not contain data. Hybrid gateway 150 edits the received 

also sends packet #1 to hybrid terminal 110 through the 65 packet to replace the packet's ACK number 1104 with a 

satellite link. This transmission has a long propagation "spoofed" ACK number in step 1326. The spoofed ACK 

delay. When hybrid terminal 110 receives the packets, it number is determined in the same way as the ACK number 
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in step 1318 of FIG. 13(d). When hybrid gateway 150 
substitutes the spoofed ACK number 1104 in the packet, it 
also recalculates the packet's checksum 1106 in step 1326. 

In step 1328, hybrid gateway 150 forwards the received 
ACK packet to application server 140. Application server 5 
140 may simply disregard the packet if it contains an ACK 
and no data. In another embodiment, hybrid gateway 150 
simply discards a packet received from hybrid terminal 110 
that contains an ACK, but no data. 

If the connection goes down, either explicitly or after a 
predetermined period of time, hybrid gateway 150 deletes 
the saved packets for the connection, 
d. Summary 

In summary, the present invention allows a personal 
computer to send messages into the Internet using a con- 
ventional dial-up link and to download data from the Inter- 15 
net using a high-speed one-way satellite link. In a preferred 
embodiment, the invention uses a conventional SLIP pro- 
vider to connect to the Internet and uses a commercial 
software TCP/IP package that has a standard driver inter- 
face. A spoofing protocol compensates for the long propa- 20 
gation delays inherent to satellite communication. 

II. SELECTIVE SATELLITE OR TERRESTRIAL 
LINK 

According to a second embodiment of the present 25 
invention, information downloaded from the Internet may be 
selectively received via a high-speed link, or a lower speed 
link, such as a terrestrial link, as described in detail below. 
In a preferred embodiment, the high-speed link is a satellite 
link. It is understood, however, that other high speed links, 30 
such as cable television lines or the like, may be used. 
Similarly, the terrestrial link may be any low-speed network, 
such as a TCP/IP network, dial-up telephone, ISDN 
D-channel, or CPDP. 

a. General Overview 35 

As set forth above, the use of the satellite link to download 
information from the Internet has many advantages, such as 
high bandwidth capability. There may be some applications, 
however, when a user may prefer to use a terrestrial link, 
rather than a satellite link, to download information from the 40 
Internet. For example, because of the distance of the satellite 
from earth, the response time using a satellite link may be 
approximately 600 ms, as opposed to approximately 300 ms 
for a terrestrial link. Thus, in applications which are sensi- 
tive to response time, such as Telnet or domain name 45 
lookups, a terrestrial link may be preferred. 

Also, a user of the satellite link is generally charged based 
on the amount of time the satellite link is used. Thus, in order 
to control costs of the satellite link service, a user may prefer 
to use a terrestrial link for applications, such as Progressive 50 
Networks and Real Audio, where the high bandwidth and 
speed of the satellite link is not important but the amount of 
total traffic (measured in megabytes) is great. 

Further, many Internet dial-up service providers offer 
value-added services (such as Usenet news or customer 55 
service evaluations) that are only accessible by their sub- 
scribers. Many of these providers verify that a user is a 
subscriber by checking the source IP address of the user's 
request. Because the satellite link effectively changes the 
source IP address of the request, the provider will not 60 
recognize the request and, consequently, the user may not be 
able to access the value-added services. Thus, a user may 
prefer to use a terrestrial link (which does not effect the 
source IP address) in order to access certain value-added 
services. 65 

Therefore, the second embodiment of the present inven- 
tion allows a user to selectively bypass the above-described 
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satellite link and use a terrestrial link to retrieve information 
from the Internet. 

b. Selecting the Terrestrial Link 

In a preferred embodiment, the hybrid terminal 110 
includes a graphical user interface (GUI) which allows a 
user to select a list of applications that will use the terrestrial 
link, rather than the satellite link, for retrieving information 
from the Internet 128. An example of a user interface 1410 
is shown in FIG. 14. The interface 1410 allows a user to 
select which applications will use the terrestrial link 
(referred to hereafter as "terrestrial applications"). For 
example, applications such as Telnet, Finger and Ping, 
which require fast response time but low bandwidth, may be 
selected to use the terrestrial link. The hybrid terminal 110 
may also be configured such that these applications (and/or 
other applications) are routed through the terrestrial link by 
default. 

Each application is assigned a specific TCP/UDP 
(transmission control protocol/user datagram protocol) port 
number (designated by reference number 1412 in FIG. 14). 
For example, web browsing applications are assigned to port 
no. 80, telnet applications are assigned to port no. 23, etc. A 
user may select terrestrial applications by specifying the 
TCP/UDP port number (or another type of protocol identi- 
fication number, if applicable) for the application. A user 
may change the list of selected terrestrial applications at any 
time. 

Preferably, the graphical user interface of the hybrid 
terminal 110 also allows the user to designate one or more 
IP address ranges, when such address ranges can only be 
accessed terrestrially. For example, the designated address 
range could correspond to the addresses of the ISP value- 
added services. The hybrid terminal 110 would route any 
data packet with a destination address falling within a 
designated address range over the terrestrial link. 

Preferably, even if an application was not prespecified by 
a user as a terrestrial application, a user may specify 
"on-the-fly" that all applications should be routed over the 
terrestrial link. This may be implemented, for example, by 
incorporating a pull-down menu in the user interface which 
allows a user to specify all applications as terrestrial. Once 
specified, all information retrieved from the Internet would 
be received over the terrestrial link until the user specifies 
that only the pre -selected applications should use the ter- 
restrial link. A user may also be able to specify "on-the-fly" 
that a single application be routed over the terrestrial link. 

Further, the hybrid terminal 110 could be modified to 
automatically select the terrestrial link if, for example, the 
satellite link malfunctions. The satellite receiver 180 is able 
to detect a loss of receive signal that may be caused, for 
example, by rain attenuation, antenna misalignment, system 
failures, etc. Upon detecting a failure in the satellite link, the 
hybrid terminal could automatically switch to the terrestrial 
link. Similarly, if the hybrid gateway 150 detects that the 
satellite link is congested or overloaded, it could route a 
portion of the data over the terrestrial link in order to relieve 
the congestion. Selected data packets received by the hybrid 
gateway for transmission over the satellite link could be 
modified and returned to the Internet for re-routing over the 
terrestrial link. 

The selective satellite or terrestrial link also serves as a 
trouble shooting tool in the system. Thus, problems with the 
terrestrial link (such as with the dial-up ISP) can be isolated 
from the satellite service equipment. The satellite link may 
serve as a back-up if the terrestrial link fails, and vice versa. 

c. The Terrestrial Link 

Referring to the hardware diagram of FIG. 1, the sub- 
systems for the second embodiment of the invention remain 
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unchanged, except that the software in driver 114 in the 
hybrid terminal 110 is modified to allow for selective use of 
the satellite link or the terrestrial link to retrieve information 
from the Internet 128. (The modified driver will be referred 
to as driver 11 4A). The terrestrial link comprises the path 
from application server 140 to the Internet 128 to the serial 
port 122 in the hybrid terminal 110 via the SLIP provider 
130 and the modem 190. The SLIP provider 130 may 
alternatively be a PPP (point to point protocol) provider. 

FIG. 15 is a simplified hardware diagram of the present 
invention depicting the satellite and terrestrial paths for 
requesting and receiving information from the Internet 128. 
The satellite request path for sending a request from the 
hybrid terminal 110 to the application server 140, wherein 
the response is to be returned via the satellite link, is shown 
by the solid arrows labeled "A". The satellite request path 
"A" originates with the hybrid terminal 110, which sends a 
data request packet via the SLIP provider. As described in 
detail above, the driver 114A in the hybrid terminal 110 
"tunnels" the request packet such that the request packet is 
routed to the hybrid gateway 150 via the Internet 128. The 
hybrid gateway 150 "untunnels" the packet and sends it back 
to the Internet 128 for routing to the application server 140. 

The satellite reply path for sending a reply from the 
application server 140 to the hybrid terminal 110 via the 
satellite link is shown by the solid arrows labeled "B" in 
FIG. 15. As explained in detail above, the application server 
140 is "fooled" into sending reply packets to the hybrid 
terminal 110 through the hybrid gateway 150 and the 
satellite link, rather than returning the reply packets to the 
sender (i.e. SLIP provider 130). 

The terrestrial request path for sending a request from the 
hybrid terminal 110 to the application server 140, wherein 
the response is to be returned via the terrestrial link, is shown 
by the dashed arrows labeled "C in FIG. 15. Like the 
satellite request path "A", the hybrid terminal 110 sends a 
data request packet to the SLIP provider 130. Unlike the 
satellite request packet, however, the driver 114A does not 
tunnel the request packet to the hybrid gateway 150. Instead, 
in the terrestrial request path "C", the request is routed 
directly from the SLIP provider 130 to the application server 
140 via the Internet 128. 

The terrestrial reply path from the application server 140 
to the hybrid terminal 110 via the terrestrial link is shown by 
the dashed arrows labeled "D" in FIG. 15. The terrestrial 
reply path "D" is the reverse of the terrestrial request path 
"C". Thus, the application server 140 sends the reply packets 
directly to the SLIP provider 130 via the Internet 128. The 
SLIP provider 130 then transmits the reply packets to the 
hybrid terminal 110. 

d. Packet Handling for the Terrestrial Link 

The following paragraphs describe how the request and 
reply packets are manipulated for transmitting packets via 
the terrestrial link. FIG. 16 is a simplified block diagram 
illustrating the relationship between the TCP/IP software 
210 (included in application software 112), the software in 
the modified satellite/terrestrial driver 114A, the serial port 
122, and the satellite interface 120 in the hybrid terminal 
110 

As described in detail above, the TCP/IP software 210 
generates a request packet and provides the request packet to 
the driver 114A. FIG. 16 A is a simplified diagram of an 
original request packet sent from the TCP/IP software 210 to 
the driver 114A. Referring also to FIG. 16, the point "A" 
represents the original request packet shown in FIG. 16A. As 
explained in detail above, the original request packet gen- 
erated by the TCP/IP software 210 has a destination address 
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(DA) of the application server 140 and a source address (SA) 
of the satellite interface 120. The original request packet also 
includes an IP header checksum (the sum of the numbers 
making up the source and destination addresses) and a 
TCP/UDP checksum (the sum of the numbers making up the 
entire packet). The checksums are used to determine 
whether the packets have been accurately transmitted, with- 
out corruption of the addresses or data. The original request 
packet also includes the request data. 

Also, as explained in detail above, if the request is to be 
returned via the satellite link (i.e. the user has not designated 
the application generating the request as a terrestrial 
application), the driver 114A "tunnels" the packet inside 
another packet and sends the tunneled packet over the serial 
port 122 to the SLIP provider 130. The tunneled packet, 
which is shown in FIG. 16B and represented by point "B" 
on FIG. 16, includes a new destination address correspond- 
ing to the hybrid gateway 150 and a new source address 
corresponding to the SLIP provider 130. The tunneled 
packet also includes a new IP header checksum correspond- 
ing to the new destination and source addresses. The remain- 
der of the tunneled packet comprises the original request 
packet provided to the driver 114A from the TCP/IP soft- 
ware 210. 

Alternatively, if the user has selected the application 
generating the request as a terrestrial application, the driver 
U4Adoes not "tunnel" the packet. Instead, as shown in FIG. 
16C and represented by point "C" on FIG. 16, the driver 
114A changes the source address of the original request 
packet from the satellite interface to the SLIP provider. The 
destination address (corresponding to the application server) 
and the request data remain the same as in the original 
packet. The IP header checksum and TCP/UDP checksum 
are also modified consistent with the change of the source 
address. 

The terrestrial request packet of FIG. 16C is routed via the 
terrestrial request path (path "C" in FIG. 15). The SLIP 
provider 130 receives the packet from the serial port 122 and 
sends the packet to the destination address (i.e. the applica- 
tion server 140) via standard Internet routing. The applica- 
tion server 140, in turn, responds to the request by sending 
a terrestrial reply packet, as shown in FIG. 16D. The 
application server 140 addresses the reply packet to the 
source address of the request (i.e. the SLIP provider 130). 
Thus, the terrestrial reply packet from the application server 
140 has a destination address corresponding to the SLIP 
provider 130 and a source address corresponding to the 
application server 140. The terrestrial reply packet also 
contains an appropriate IP header and TCP/UDP checksum 
and the reply data. 

The terrestrial reply packet is sent from the application 
server 140 via standard Internet routing to the SLIP provider 
130. The SLIP provider 130 then sends the reply packet to 
the serial port 122 in the hybrid terminal 110. The terrestrial 
reply packet provided to the serial port 122 is represented by 
point "D" on FIG. 16. 

The driver U4A receives the terrestrial reply packet from 
the serial port 122 and modifies the reply packet by changing 
the destination address from the SLIP provider to the satel- 
lite interface, as shown in FIG. 16E. The driver 114A 
changes the destination address to the satellite interface 
because, as described in detail above, the TCP/IP software 
210 is configured with an IP address corresponding to the 
satellite interface. Thus, the TCP/IP software will not rec- 
ognize the terrestrial reply packet unless the reply packet 
includes the proper IP address of the satellite interface for 
the TCP/IP software. The driver 11 4A also changes the IP 
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header checksum and the TCP/UDP checksum consistent 
with the new destination address. The modified terrestrial 
reply packet is represented by point "E" on FIG. 16. 

e. Automatic Selection of the Terrestrial Link 

As described above, the hybrid gateway 150 may auto- 5 
matically route applications over the terrestrial link if, for 
example, the satellite link becomes congested. The hybrid 
gateway 150 may also automatically select the terrestrial 
link if a "streaming" application is used. A streaming appli- 
cation is a continuously running application (such as audio, 10 
video, slide shows, etc.) as opposed to applications which 
run in segments or bursts (such as web browsing). Streaming 
applications generally occupy an inordinate share of the 
satellite link, which may become prohibitively expensive for 
the user. Therefore, the hybrid gateway 150 may be config- 15 
ured to automatically detect packets which are part of a 
streaming application and route them over the terrestrial 
link. 

The hybrid gateway 150 may detect a streaming applica- 
tion for routing over the terrestrial link by examining the 20 
header on the data packet. Generally, UDP (user datagram 
protocol) packets are part of a streaming application. Thus, 
the hybrid gateway 150 could assume that all UDP packets 
are streaming applications and route them over the terrestrial 
link. 25 

Alternatively, the hybrid gateway 150 could detect 
streaming applications by monitoring the traffic character- 
istics of TCP connections. Generally, streaming applications 
run for an extended period of time at a bit rate consistent 
with a conventional dial-up connection (i.e., under 30 Kbit/ 30 
sec). Also, any connection which has carried more than, for 
example, 12 Megabytes may be assumed to be a streaming 
application. Thus, the hybrid gateway 150 could automati- 
cally route packets with these traffic characteristics over the 
terrestrial link. 35 

As described in section (e) above, the hybrid gateway 150 
could automatically route selected packets over the terres- 
trial link by changing the destination address of the packet 
to the SLIP provider and recalculating the IP header and 
TCP/UDP checksums accordingly. Thus, the hybrid gateway 40 
modifies the packet into a terrestrial reply packet as shown 
in FIG. 16D. This reply packet is then sent via standard 
Internet routing to the SLIP provider 130. The SLIP provider 
130, in turn, sends the packet to the driver 114Ain the hybrid 
terminal 110 via the serial port 122. The driver 11 4A 45 
receives the reply packet and changes the destination 
address to the satellite interface and recalculates the 
checksums, as described above in connection with FIG. 16E. 

f. Summary 

The second embodiment of the invention allows a user to 50 
specify that certain applications will retrieve data from the 
Internet over the terrestrial link, rather than over the satellite 
link. Generally, a user may prefer to use the terrestrial link 
for applications (such as Telnet) that require faster response 
time. The user may also select the terrestrial link to control 55 
costs associated with the satellite link or to access certain 
value-added services. The hybrid gateway may also auto- 
matically select certain applications such as streaming 
applications, to be routed over the terrestrial link. Data is 
routed over the terrestrial link by modifying the IP addresses 60 
of data packets in the hybrid terminal. 

Other embodiments of the invention will be apparent to 
those skilled in the art from consideration of the specifica- 
tion and practice of the invention disclosed herein. It is 
intended that the specification and examples be considered 65 
as exemplary only, with the true scope of the invention being 
indicated by the following claims. 
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We claim: 

1. A system for retrieving data from a source computer 
coupled to a network, comprising: 

a requesting terminal; 

a low-speed path linking the requesting terminal with the 
network; 

a high-speed path linking the requesting terminal with the 
network; and 

selection means for selecting one of the low-speed path 
and the high speed path for transmission of data from 
the source computer to the requesting terminal, 

wherein the requesting terminal includes application soft- 
ware for generating a data request packet for transmis- 
sion from the requesting terminal to the source 
computer, 

wherein the selection means comprises a driver for receiv- 
ing the data request packet from the application soft- 
ware and modifying the request packet to specify one 
of the low-speed path and the high-speed path for 
transmission of data from the source computer, and 

wherein the request packet is an IP packet including a 
destination address and a source address and the driver 
specifies the low-speed path by changing the source 
address to correspond to the low-speed path, 

2. The system of claim 1, wherein the request packet is an 
IP packet including a destination address and a source 
address and the driver specifies the high-speed path by 
tunneling the packet. 

3. The system of claim 1, wherein the selection means 
further comprises a user interface in the requesting terminal 
that allows a user to specify an application to use the 
low- speed path. 

4. The system of claim 3, wherein the driver modifies the 
request packet to specify one of the low-speed path and the 
high-speed path based on the user's specification. 

5. A system for retrieving data from a source computer 
coupled to a network, comprising: 

a requesting terminal for requesting data to be retrieved 
from the source computer, wherein the requesting ter- 
minal includes 

a terrestrial interface coupled to the network; 

a satellite interface capable of receiving data transmitted 
via a satellite link, wherein the satellite link includes a 
gate coupled to the network, and means for designating 
that the requested date be transmitted from the source 
computer to the requesting terminal through one of the 
terrestrial interface and the satellite interface, 

wherein the requesting terminal transmits a request packet 
to the source computer through the terrestrial interface, 

wherein the designating means comprises a driver that 
modifies the request packet to specify one of the 
terrestrial interface and the satellite interface, and 

wherein the driver specifies the terrestrial interface by 
changing the source address of the request packet to the 
terrestrial interface. 

6. The system of claim 5, wherein the driver specifies the 
satellite interface by adding a new destination address 
corresponding to the gateway and a new source address 
corresponding to the terrestrial interface to the request 
packet. 

7. The system of claim 5, wherein the designating means 
comprises the gateway which modifies the destination 
address of the request packet to correspond to the terrestrial 
interface. 

8. The system of claim 5, wherein the designating means 
automatically designates that the requested data be trans- 
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mitted through the terrestrial interface when the request 
packet corresponds to a streaming application. 

9. The system of claim 5, wherein the designating means 
automatically designates that the requested data be trans- 
mitted through the terrestrial interface when the satellite link 5 
malfunctions. 
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10. The system of claim 5, wherein the designating means 
automatically designates that the requested data be trans- 
mitted through the terrestrial interface when the satellite link 
is congested. 
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